1. Field of the Invention
The present invention relates to a System and Method for Controlling Network Access.
2. Description of the Relevant Art
In recent years, public and private enterprises of all sizes have installed an increasingly large array of telecommunications systems, information systems, and other products which serve as the operational infrastructure for day-to-day business activities.
However, providers of these products, systems, and services have long had issues concerning integrating with the access and authentication schemes of their customers' systems and equipment for providing testing, upgrades, and maintenance. In particular, these providers and servicing companies find it difficult to comply with a multitude of remote access requirements and differing remote access and authorization packages used by their customers. Moreover, managing all of the third party technicians, business partners and outsourcers that need remote access to products and systems used by an extended user base of customers is an issue terms of cost and resources.
Enterprise customers typically have Authentication/Authorization/Administration (AAA) servers located at their site to identify, control, log users.
AAA servers provide:                Authentication: the process of identifying and verifying a user.        Authorization: determines what a user can do        Administration: the action of recording what a user is doing or has done        
FIG. 1 shows a conventional Authentication/Authorization/Administration (AAA) Server 50 in the context of a representative customer network environment. FIG. 1 also illustrates customer VPN Gateway 51, and products 52, 53 (for example, PBXs).
Access by the Service Provider technician is accomplished by access device 40 via the Internet. Conventionally, customers requiring user authentication ask the Service Provider's technicians to use their Virtual Private Network (VPN) client (not shown) and their hard token, such as Secure ID. For a Service Provider having only a few service technicians, this may be a viable option. However, for a provider with hundreds or thousands of technicians, this becomes almost impossible.                Each service technician would need to install every customer's VPN client onto their PC. Since VPN clients typically modify the PC's TCPIP stack, the service provider's PC may no longer function properly.        Each technician would need to manage hundreds and possibly thousands of hard tokens for all the customers serviced. This would become un-manageable for both the provider and the customer. When customers are asked about this possibility, they agree a better solution is needed.        There is no requirement that a Service Provider open a trouble ticket or work ticket prior to authentication.        
There are numerous companies such as RSA Security, Inc. and Ion Networks, Inc. that provide hard and soft token-based remote access control solutions. The solution works well for associates of a single company accessing their own devices. In an outsourced or third-party maintenance scenario it requires that the entire extended technician force, including all third-party technicians, be set up in the customer's access control system and assigned an individual hard or soft token. For the external maintenance company the requirement to keep up with a hard token device for each technician for each customer is a significant problem of cost and maintenance.
Companies such as Permeo Technologies, Inc. offer turnkey desktop to device authorization and remote access control solutions. This solution works well for associates of a single company accessing their own devices. It requires that all remote users purchase and use the exact same set of software and that the entire extended technician force, including all third-party technicians, be set up in the customer's access control system. This is a cost burden and for a third-party management company since it is not feasible to provide all the various configurations and software required for every customer's chosen turnkey solution to every technician.
The Liberty Alliance and Security Assertion Markup (no dash) Language (SAML) organizations are developing a trust based identity and authorization exchange standard for web-based business-to-business operations. This standard effort is focusing entirely upon web-based business-to-business transactions and applications. The protocols and access requirements for remote maintenance, monitoring and support extend far beyond web based access to applications.
The SOCKS Internet Request for Comments (RFC 1928, 3089 and 1929) provides a protocol for establishing access to network devices using a proxy service. The proxy service can implement access and authorization controls to devices behind the proxy. The current standards cover the use of user ID and password based authorization control as well as support for the Generic Security Services Application Programming Interface (GSSAPI) to allow additional authorization models to be established based upon the agreement of the client application and the proxy.
More information on these is described in:                Netegrity Role Management: http://www.netegrity.com/news/webseminararchive/rolesarchive.html        Permeo Outbound Access: http://www.permeo.com/outboundaccess.htm        ION Networks Secure remote access: http://www.ionnetworks.com/priisms.shtml        
Given the problems described above, what is needed going forward is a means to separate the three AAA functions so Authentication is performed at the Service Provider's site and the user's identity and associated roles is passed to the customer's site when access is requested. Authorization and Administration is then performed at the customer's site.